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DIGITAL LIVING NETWORK ALLIANCE (DLNA) GUIDELINES 

Part 7: Authentication 


1 Scope 

This part of IEC 62481 specifies DLNA interoperability guidelines for device authentication. 

The DLNA interoperability guidelines are based on a device authentication solution, which is 
defined as methods to enable authentication of a client device as DLNA Certified. Methods are 
included to allow a client device to authenticate a server device as trusted by a Certificate 
Authority. 

The guidelines are intended to supplement other interoperability mechanisms already defined 
for DLNA link protection and DLNA DRM interoperability solutions. 

2 Normative References 

The following documents, in whole or in part, are normatively referenced in this document and 
are indispensable for its application. For dated references, only the edition cited applies. For 
undated references, the latest edition of the referenced document (including any amendments) 
applies. 

IEC 62481-1, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 1: Architecture and protocols 

IETF RFC 2616, Hypertext Transfer Protocol, 
http://www.ietf.org/rfc/rfc2616.txt 

IETF RFC 2818, HTTP over TLS , Informational, 
http://tools.ietf.org/html/rfc2818 

IETF RFC 4680, TLS Handshake Message for Supplemental Data, 
http://tools.ietf.org/html/rfc4680 

IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, 
http://tools.ietf.org/html/rfc5246 

IETF RFC 5280, Internet X. 509 Public Keylnfrastructure Certificate and Certificate Revocation 

List (CRL) Profile, 

http://tools.ietf.org/html/rfc5280 

IETF RFC 5878, Transport Layer Security (TLS) Authorization Extensions, 
http://tools.ietf.org/html/rfc5878 

IETF RFC XXXX, <TDB> Authentication Credential Exchange Using TLS Supplemental Data, 
https://datatracker.ietf.org/doc/draft-dthakore-tls-authz/ 

DTCP Volume 1 (informational version), Digital Transmission Content Protection Specification 
Volume 1, Revision 1.7, 

http://www.dtcp.com/documents/dtcp/info-20111214-dtcp-v1-rev-1-p-7.pdf 

3 Terms, definitions, symbols and abbreviated terms 

For the purposes of this document, the terms, definitions, symbols and abbreviated terms in 
IEC 62481-1 and thefollowing apply. 

3.1 GeneralTerms 

3.1.1 Authentication Client 

a set of device functions, as part of the Client Authentication Device Option, provides the 
protocols to allow a client to be authenticated and the protocols to authenticate an 
Authentication Server by verifying the Server credentials. 
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3.1.2 Authentication Server 

a Device Function that, as part of the Server Authentication Device Option, provides the 
protocols to allow a server to be authenticated and the protocols to authenticate an 
Authentication Client by verifying the Client credentials. 

3.1.3 Client Authentication 

process or action where the Authentication Client initiates the authentication request for the 
Authentication Server to authenticate the Client. 

3.1.4 DTCP Method 

occurs when a device uses a device certificate for itself during DLNA Authentication 

3.1.5 Server Authentication 

process or action where the Authentication Server is authenticated by the Authentication Client 

3.1.6 X.509 Method 

occurs when a device uses an X.509 credential for itself during DLNA Authentication. No DTCP 
device certificate is used with this method 

3.2 Conventions 

In IEC 62481-1 and this document, a number of terms, conditions, mechanisms, sequences, 
parameters, events, states, or similar terms are printed with the first letter of each word in 
uppercase and the rest lowercase (e.g. Move.) Any lowercase uses of these words have the 
normal technical English meanings. 

4 Networking Architecture and Guideline Conventions 

4.1 DLNA Home Networking Architecture 

This document extends the DLNA Home Networking Architecture that is defined in clause 4, 
IEC 62481-1. 

4.2 Document conventions 

See clause 6, IEC 62481-1, for a description of the DLNA document conventions. 

4.3 Guideline structure 

See clause7.1 in IEC 62481-1, for guideline and attribute table layout descriptions. 

5 DLNA Device Model 

Refer to clause 5, IEC 62481-1, for detailed descriptions of existing DLNA Home Networking 
Architecture Device Model. This document extends the existing DLNA System Usages. 

5.1 Authentication Device Functions 

The architecture consists of system elements in the home and outside the home used to 
implement the DLNA authentication feature. These elements support both service provider and 
home owner use cases. Figure 1 is an overview of the architecture. 
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Figure 1 —Authentication functions 

The architecture defines the following functions. 

• Credential Authority - Creates client and server credentials for use by manufacturers in their 
devices. Provides root certificate(s) to the Authentication Server and the Authentication 
Client. Defines the robustness requirements. 

• Client Credential Installation - Installs the credentials into the client device. Performed by 
the manufacturer. 

• Client Credential Storage - Stores the credentials accordingtothe robustness requirements. 
Provides access to the credentials by the Authentication Server. 

• Server Credential Storage - Stores the credentials according to the robustness 
requirements. Provides access to the credentials by the Authentication Server. 

• Authentication Client - Authenticates with the Authentication Server and authenticates 
servers using the Server Credentials. 

• Authentication Server - Authenticates with the Authentication Client and authenticates 
clients using the Client Credentials. 
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The DLNA guidelines will cover interoperability between the Authentication Client Function and 
the Authentication Server Function. 

5.2 Device Options 

For the Authentication Interoperability Guidelines and System Usages, the following Device 
Options are defined. 

• Client Authentication: A Device Option that consists of an Authentication Client Function and 
Client Credentials. 

• Server Authentication: A Device Option that consists of an Authentication Server Function 
and Server Credentials. 

5.3 System Usages 

DLNA Authentication Guidelines are designed to complement all DLNA Device Classes and 
Device Capabilities in all System Usages, providing and enabling them the ability to authenticate 
each other securely before other functions, such as content transports, can be performed . Other 
than adding the authentication processes as described in 3.1.3 and 3.1.5, all DLNA System 
Usages stay the same. 

While some of the implementations of DLNA System Usages require device authentication, 
many do not. As such, DLNA Authentication Guidelines are optional (a.k.a Device Options) and 
it is an implementer’s choice to implement them. 

Although an Authentication Server or an Authentication Client may be implemented as an 
independent entity that performs authentication only without any other function, this type of 
implementation does not make sense because there is no purpose to authenticate. Therefore, 
the authentication services are designed as Device Options that shall be a part of a Device Class 
or Device Capability when implemented. 

5.4 Theory of Operation 

The enclosed guidelines enable the ability for a server to authenticate a client as a DLNA 
certified device using either X.509 credentials or device certificates. Conversely the ability for a 
client to authenticate a server is also supported. The TLS protocol using the SupplementalData 
payload mechanism is defined herein to support both client and server authentication using 
DTCP certificates. 

The authentication scenarios covered are as follows. 

1. Server uses trusted X.509 and client uses trusted X.509 

2. Server uses trusted X.509 and client uses DTCP 

3. Server uses (trusted or self-signed X.509) + DTCP, and client uses trusted X.509 

4. Server uses (trusted or self-signed X.509) + DTCP, and client uses DTCP 

The first scenario is supported by standard TLS protocol. The rest ofthe scenarios require use 
of SupplementalData extensions to TLS protocol. Scenario #3 is highly unlikely to occur in 
practice due to the typical nature of a TLS handshake. A TLS handshake is triggered by a TLS 
client sending a ClientHello message and if the TLS client does not indicate support for the 

DTCP method, a TLS server will not be allowed to send the DTCP certificate. So a TLS client is 

required to have a priori knowledge that a particular TLS server is using DTCP certificate . 

6 Guideline requirements 

6.1 Device discovery and control 

6.1.1 Authentication Server discovery 

6.1.1.1 

[GUIDELINE] a DLNA Device Class or Device Capability that indicates support for the Server 
Authentication Device Option shall implement the requirements specified for Authentication 
Server. 
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[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

n/a 

W3UP4 

N 



+ RUIHSRC+ 







[COMMENT] Support for Server Authentication Device Option is indicated at the time of 
registration for certification. 

6.1.1.2 

[GUIDELINE] a DLNA Device Class or Device Capability that implements the Authentication 
Server shall have the capID value of “authentication-server” for the dlnacap-value in the 
<dlna:X_DLNACAP> element, as defined in IEC 62481-1, of the Device Description document. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IEC 62481-1 

GX4I8 

N 



+ RUIHSRC+ 







[COMMENT] This is where a UPnP control point checks if the DLNA Device Class or Device 
Capability implemented the Authentication Server after retrieving the Device Description 
document of the UPnP Device. 

6.1.2 Authentication Client discovery 

[GUIDELINE] a DLNA Device Class or Device Capability that indicates support for the Client 
Authentication Device Option shall implement the requirements specified for Authentication 
Client. 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

n/a 

ENEWV 

N 



+ PU+, +RUIHPL + 







[COMMENT] Support for Client Authentication Device Option is indicated at the time of 
registration for certification. 

6.2 Authentication guidelines 

6.2.1 Authentication Server protocols 

6 . 2 . 1.1 

[GUIDELINE] The Authentication Server shall implement HTTP 1.1 Server. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 2616 

7LRZP 

N 



+ RUIHSRC+ 







[COMMENT] The Device Class or Device Capability that implements the Authentication Server 
could already have the HTTP 1.1 Server implemented. This guideline establishes the basis for 
interoperability however other protocols could also be used. 

6.2.1.2 

[GUIDELINE] The Authentication Servershall implement HTTPS (HTTP over TLS). 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 2818 

ABKQG 

N 



+ RUIHSRC+ 







[COMMENT] The Device Class or Device Capability that implements the Authentication Server 
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could already have HTTPS implemented. This guideline establishes the basis for interoperability 
however other protocols could also be used. 

6 . 2 . 1.3 

[GUIDELINE] The Authentication Server shall implement the TLS1.2 protocol as defined in 
IETF RFC 5246. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 5246 

WM9P4 

N 



+ RUIHSRC+ 







6 . 2 . 1.4 

[GUIDELINE] The Authentication Server shall implement the TLS SupplementalData handshake 
message as defined in IETF RFC 4680. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 4680 

JY8N9 

N 



+ RUIHSRC+ 







6.2.1.5 

[GUIDELINE] The Authentication Server shall implement the client_authz and server_authz TLS 
Hello message extensions as defined in IETF RFC 5878 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 5878 

7TRPH 

N 



+ RUIHSRC+ 







[COMMENT] When a server uses the TLS SupplementalData message to send its credentials, it 
will do so by indicating support for these extensions in the Hello message. 

6.2.2 Authentication Client protocols 

6.2.2.1 

[GUIDELINE] The Authentication Client shall implement HTTP 1.1 Client. 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 2616 

ME837 

N 



+ PU+, +RUIHPL + 







[COMMENT] The Device Class or Device Capability that implements the Authentication Client 
could already have the HTTP 1.1 Client implemented. This guideline establishes the basis for 
interoperability however other protocols could also be used. 

6 . 2 . 2.2 

[GUIDELINE] The Authentication Client shall implement HTTPS (HTTP over TLS). 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 2818 

8USPH 

N 



+ PU+, +RUIHPL + 







[COMMENT] The Device Class or Device Capability that implements the Authentication Client 
could already have HTTPS implemented. This guideline establishes the basis for interoperability 
however other protocols could also be used. 

6 . 2 . 2.3 

[GUIDELINE] The Authentication Client shall implement the TLS1.2 protocol as defined in 
IETF RFC 5246. 
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[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 5246 

BC6YY 

N 



+ PU+, +RUIHPL + 







6 . 2 . 2.4 

[GUIDELINE] An Authentication Client that implements the DTCP Method shall implement the 
TLS SupplementalData handshake message as defined in IETF RFC 4680. 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 4680 

GM2LB 

N 



+ PU+, +RUIHPL + 







6.2.2.5 

[GUIDELINE] An Authentication Client that implements the DTCP Method shall implement the 
client authz and server_authz TLS Hello message extensions as defined in IETF RFC 5878 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 5878 

TCEMN 

N 



+ PU+, +RUIHPL + 







[COMMENT] When a client uses the TLS SupplementalData message to send its credentials, it 
will do so by indicating support for these extensions in the Hello message. 

6.2.3 Client Authentication guidelines 

6.2.3.1 

[GENERAL] 6.2.3 defines all functionality required for performing Client Authentication. 

6.2.3.2 

[GUIDELINE] An Authentication Client shall implement one of the following authentication 
methods for client authentication: 

• X.509 Method as defined in 6.2.3.3. 

• DTCP Method as defined in 6.2.3.5 through 6.2.3.6. 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

n/a 

AQ7AC 

N 



+ PU+, +RUIHPL + 







[COMMENT] Authentication occurs via one of 2 separate credential mechanisms. 

6.2.3.3 

[GUIDELINE] If an Authentication Client implements the X.509 Method as defined in 
IETF RFC 5280 for Client Authentication, then it shall support TLS1.2 for Client Authentication 
as defined in IETF RFC 5246. 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 5246 

LWI79 

N 



+ PU+, +RUIHPL + 



IETF RFC 5280 




6.2.3.4 

[GUIDELINE] If an Authentication Client implements the DTCP Method, then it shall implement 
all client requirements defined in IETF RFC XXXX including generating, processing and error 
handling of SupplementalData messages. 
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[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR,, 

M-DMP M-DMC 

n/a 

IETF RFC XXXX 

52ZEM 

N 



+ PU+, +RUIHPL + 







6.2.3.5 

[GUIDELINE] If an Authentication Client implements the DTCP Method, then it shall use the TLS 
SupplementalData Double Handshake as defined in IETF RFC XXXX. 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC XXXX 

L8SLI 

N 



+ PU+, +RUIHPL + 







6.2.3.6 

[GUIDELINE] If an Authentication Client implements the DTCP Method, then it shall generate 
the SupplementalData message as defined in IETF RFC XXXX that includes the device 
certificate as defined in DTCP Volume 1. 

[ATTRIBUTES] 


M 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC XXXX 

QA9QL 

N 



+ PU+, +RUIHPL + 



DTCP Volume 1 




[COMMENT] The device certificate will include sufficient information that authenticates the 
client. 

6.2.3.7 

[GUIDELINE] An Authentication Server shall implement the DTCP Method as defined in 6.2.3.5 
for Client Authentication. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 5246 

R9BVI 

N 



+ RUIHSRC+ 







6.2.3.8 

[GUIDELINE] An Authentication Server shall implement the X.509 Method as defined in 6.2.3.3 
for Client Authentication. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 5246 

V224M 

N 



+ RUIHSRC+ 







6.2.4 Server Authentication guidelines 

6.2.4.1 

[GENERAL] 6.2.4 defines all functionality required for performing server authentication. 

6.2.4.2 

[GUIDELINE] An Authentication Server shall implement one of the following authentication 
methods for Server Authentication: 

• X.509 Method as defined in 6.2.4.3. 

• DTCP Method as defined in 6.2.4.4 through 6.2.4.6. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

n/a 

H9CSO 

N 



+ RUIHSRC+ 
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[COMMENT] Authentication occurs via one of 2 separate credential mechanisms. An 
Authentication Server using device certificates also provides an X.509 credential in order to 
establish a secure TLS session. The client can determine the authentication method based on 
the payload of the SupplementalData message. 

6.2.4.3 

[GUIDELINE] If an Authentication Server implements the X.509 Method as defined in 
IETF RFC 5280 for Server Authentication then it shall support TLS 1.2 for Server Authentication 
as defined in IETF RFC 5246. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 5246 

OGMFZ 

N 



+ RUIHSRC+ 



IETF RFC 5280 




[COMMENT] The X.509 credential includes sufficient information to authenticate the server. 

6.2.4.4 

[GUIDELINE] If an Authentication Server indicates support for the server_authz extension as 
defined in IETF RFC 5878, then it shall also indicate support for the client authz extension as 
defined in IETF RFC 5878. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC 5878 

SEAU2 

N 



+ RUIHSRC+ 







[COMMENT] The server_authz and client authz extensions are carried within the 
SupplementalData payload. 

6.2.4.5 

[GUIDELINE] The Authentication Server shall implement all server requirements defined in 3.4 
of IETF RFC XXXX including generating, processing and error handling of SupplementalData 
messages. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC XXXX 

TUX52 

N 



+ RUIHSRC+ 







6.2.4.6 

[GUIDELINE] If an Authentication Server implements the DTCP Method for Server 
Authentication, then it shall create and send the SupplementalData message that includes the 
device certificate as per IETF RFC XXXX. 

[ATTRIBUTES] 


M 

A 

DMS, DMR, XDMR, 

M-DMS 

n/a 

IETF RFC XXXX 

ZOETF 

N 



+ RUIHSRC+ 



DTCP Volume 1 




[COMMENT] The device certificate will include sufficient information that authenticates the 
server. 

6.2.4.7 

[GUIDELINE] An Authentication Client should implement the DTCP Method as defined in 6.2.4.6 
for Server Authentication. 

[ATTRIBUTES] 
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s 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 5246 

4VR09 

N 



+ PU+, +RUIHPL + 







[COMMENT] A Client Authentication Device Option will determine the authentication method the 
Server supports and respond accordingly. 

6.2.4.8 

[GUIDELINE] An Authentication Client should implement the X.509 Method as defined in 6.2.4.3 
for Server Authentication. 

[ATTRIBUTES] 


S 

A 

DMC, DMP, XDMR, 

M-DMP M-DMC 

n/a 

IETF RFC 5246 

CAV9Q 

N 



+ PU+, +RUIHPL + 







[COMMENT] A Client Authentication Device Option will determine the authentication method the 
Server supports and respond accordingly. 
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